-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use chef handler to run inspec tests #113
Conversation
successful converge with visibility with a change from:
to still need to modify to ensure json results get to the right place - right now just cli json output |
12e7dd4
to
5c6b12d
Compare
Signed-off-by: Victoria Jeffrey <vjeffrey@chef.io>
need to fix the one of the viz tests, but this works with chef visibility. |
Signed-off-by: Victoria Jeffrey <vjeffrey@chef.io>
@@ -1,37 +0,0 @@ | |||
--- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should not delete the examples. Instead we should migrate to work with the new version
@@ -46,11 +46,9 @@ | |||
# fail converge after posting report if any audits have failed | |||
default['audit']['fail_if_any_audits_failed'] = false | |||
|
|||
# inspec gem version to install(e.g. '1.1.0') | |||
default['audit']['inspec_version'] = '1.2.0' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we are going to need it for now
Signed-off-by: Christoph Hartmann <chris@lollyrock.com>
notifies :touch, "file[#{compliance_cache_directory}/#{p}]", :delayed | ||
notifies :execute, "compliance_report[#{report_collector}]", :delayed | ||
end | ||
chef_inspec 'inspec' do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
chef_inspec
feels like a strange name
@@ -1,7 +1,7 @@ | |||
# encoding: utf-8 | |||
|
|||
provides :chef_inspec |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can we just inspec for provides and as a resource name instead of chef_inspec
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
of course! let's do it!
quiet node['audit']['quiet'] unless node['audit']['quiet'].nil? | ||
action :nothing | ||
end if node['audit']['profiles'].values.any? | ||
inspec_report 'report' do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you think we should combine:
chef_handler 'Chef::Handler::AuditReport' do
source "#{handler_directory}/audit_report.rb"
action :enable
end
inspec_report 'report' do
action :execute
end
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how do we combine them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems like the right way to go, just unsure how?
notifies :touch, "file[#{compliance_cache_directory}/#{p}]", :delayed | ||
notifies :execute, "compliance_report[#{report_collector}]", :delayed | ||
end | ||
chef_handler 'Chef::Handler::AuditReport' do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed with @vjeffrey we try to find a way that does not require us to write a file on the host node
@@ -64,8 +64,6 @@ suites: | |||
attributes: | |||
audit: | |||
profiles: &profiles |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not 100% sure what &profiles
should refer to
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
leftover from initial implementation.. Yaml syntax docs: "Repeated nodes are first identified by an anchor (marked with the ampersand - “&”), and are then aliased (referenced with an asterisk - “*”) thereafter."
@@ -46,11 +48,9 @@ | |||
# fail converge after posting report if any audits have failed | |||
default['audit']['fail_if_any_audits_failed'] = false | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we're moving away from a resource converge I don't think 'fail_if_any_audits_failed' makes sense any more. The original intent was to fail during converge in a pipeline phase such as kitchen converge
. Now, with the report handler, we'd rely on kitchen-inspec to reference the profiles and kitchen verify
to provide a pass|fail status to the CI framework.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sounds good to me! i'll remove it
still need to figure out the chef_handler putting a source file on the system thing (https://github.com/chef-cookbooks/audit/pull/113/files#diff-55bf87238c9b8af164c5133a60721f12R9) |
1b94343
to
087609e
Compare
Most handlers that I've used lay down the handler libs as a versioned gem. One of the better examples is the DataDog handler: https://github.com/DataDog/chef-datadog/blob/master/recipes/dd-handler.rb#L32-L38 |
yup. so we were trying to avoid the gem thing in the case of an air-gapped env/to avoid outside deps (I know that doesn't make much sense right now since we are installing inspec gem but we are trying to find a way to move away from that and vendor) --- I spoke with joshua timberman and jj ashgar and both said ya, those are the only two ways of doing the chef handler thing, so i'm just gonna whip up a quick delete directory cleanup recipe and include it at the end of default with a good ol include_recipe call. coming soon! just have to make food for ppl real quick, then i'll do it :) |
directory handler_directory do | ||
recursive true | ||
action :delete | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I see what you're achieving now 😃 more clearly. However, I suppose I don't understand what the requirement is to cause us to remove the chef handler ruby library code.
To me it smells fishy because it seems like it's akin to running an app that deletes all traces of itself after execution. I can think of two potential concerns that arise from that:
- It's not in the spirit of transparency - we're running code on nodes and then deleting that code from the nodes.
- Deleting the handler code from the node could make troubleshooting harder since it requires version correlation against a git repo or chef server to determine what actual code was running when the handler fired. Having the code intact on the node gives you a 100% assurance that you know what executed.
If this moves forward, I recommend adding the standard header to the recipe which gets generated from chef generate recipe clean-up
One last thing on this commit, just me perhaps, but using -
in recipe names is not consistent with the requirement that cookbooks are not allowed to have -
in the name 😄
#
# Cookbook Name:: audit
# Recipe:: clean-up
#
# Copyright (c) 2016 The Authors, All Rights Reserved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jeremymv2 thanks for the honest feedback. That is very helpful! Background: This was an approach @vjeffrey and I discussed before. From my perspective it feels strange to install code on a node just for runtime and not cleaning the tmp stuff up. Nevertheless, if that is not standard practice we should not do this approach.
@vjeffrey I propose we leave the handler files there for now, I've an idea how we can get around generating the file in future to get the best of both worlds. But lets try that in future PRs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cool, sounds good! also, get some sleep @chris-rock!!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just updated by dropping that last commit. :) thanks for your help @jeremymv2!! good points!
Signed-off-by: Christoph Hartmann <chris@lollyrock.com>
so many more things to do. just the beginning...working on viz integration parts now.